✨ Fiche d'Aide à la Décision

FAD

-

DOCUMENT D’ANALYSE FONCTIONNEL

-

FUNCTIONAL ANALYSIS DOCUMENT

Processus Achat

Microsoft Business Central

• 1. ANAL

Sommaire

1. Introduction 3

2. Vue d‘ensemble 4

3. Planification 5

4. Traitement d‘une livraison directe 6

5. Saisie d’une demande de prix 7

6. Saisie d’une commande cadre 8

7. Saisie d’une commande d‘achat 10

8. Saisie d’un retour d’une commande achat 12

9. Rapports achat 13

10. Historique achat 14

11. Annexe 1 : Liste d‘écarts 16

1. Introduction

Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :

• Visiter les sites clients comme les usines, entrepôts et/ou bureaux
• Conduire des ateliers orientés processus.
• Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
• Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
• Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
• Identifier les volumes des référentiels et données transactionnelles
• Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
• Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.

Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :

Versions du document

Liste de diffusion

1. Vue d‘ensemble
   1. Schéma d’ensemble des processus achat

Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :

3 Planification

3.1. Contexte et Hypothèses

**3.1. Contexte et Hypothèses**

Le processus d'achat du client est actuellement basé sur un atelier achats qui gère les besoins projets, les achats génériques société et les achats mutualisés multi-projet. Les besoins projets sont anticipés ou constatés et donnent lieu à des achats spécifiques optimisés.

La chaîne d'approbation est actuellement verbale et basée sur un seuil dépendant de la personne qui passe la commande ou du risque sur la commande. Les critères d'approbation incluent l'achat dans le budget ou pas.

Les fonctionnalités souhaitées dans le système incluent le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système, l'intégration des coûts de transport liés à la commande et la prise en compte des différents plannings (fournisseur, transport, etc.).

Les hypothèses retenues incluent la nécessité d'avoir un suivi des dates d'expédition, la gestion des coûts dans le projet et la création d'un document de contrôle qualité avec rattachement de photos et tracking lot et série.

Actuellement, il n'y a pas de document d'entrée en stock, ce qui peut poser des difficultés pour le chef de projet. La gestion des projets est effectuée avec des Work-Packages, avec dates, quantités et budget.

**[INFORMATION MANQUANTE]** sur la stratégie de migration à organiser pour discuter de l’historique.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

3.2. Schéma des processus ERP : Planification 1.0

3.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "fichier article" doit être paramétré pour prendre en compte les différents types d'articles (en stock, non inventory, service).
- La gestion du multi-sourcing est mise en place, y compris la référence fournisseur.
- Les "informations de planning" (lead-time, stock de sécurité, Minimum Order Quantity, etc.) sont renseignées pour chaque fournisseur.
- Les "purchase quote" (demande d'offre) doivent être renseignées avec le numéro de projet pour lier la commande au projet.
- Les "devis" sont liés à la commande et les "commandes" (Make Order) sont créées en fonction des devis.
- La "réception" est détaillée avec quantité, rattachement à la commande et validation qualité.
- Le "contrôle qualité" est créé avec rattachement de photos, tracking lot et série, et validation par le responsable qualité.
- Les "lignes budget" sont créées pour remonter le coût budgété ou le montant réel dans la commande.
- Les "dates de planification" sont renseignées dans les lignes projet.

3.4. Documents et statistiques

**Planification**

**3.4. Documents et statistiques**

Le processus de planification de l'atelier achats implique la gestion des besoins projet, des achats génériques et des achats mutualisés multi-projet. Les besoins projet sont anticipés ou constatés et entraînent des achats spécifiques optimisés.

**Documents**

* Fiche article : les articles sont classés en trois types : en stock, non inventory et service.
* Journal des achats : les achats sont enregistrés dans le journal des achats, qui inclut les informations sur les fournisseurs, les quantités et les dates de livraison.
* Workflow validation : les demandes d'achat sont soumises à un workflow de validation, qui implique plusieurs étapes de contrôle et d'approbation.

**Statistiques**

* Tableau de bord : un tableau de bord adapté au profil de l'utilisateur fournit les informations pertinentes sur les achats et les commandes.
* Export en Excel : les données peuvent être exportées facilement en Excel pour une analyse plus approfondie.

**Certificats**

* Gestion des certificats : les certificats sont gérés par la qualité contrôle, qui les valide avant de les accepter.

**Facturation**

* Facture non payée : la facture n'est pas payée tant que la non-conformité n'est pas résolue.

**Incoterms**

* Gestion des Incoterms : les Incoterms sont gérés en utilisant le champ Shipment Method Code.

**Contrôle qualité**

* Création d'un document de contrôle qualité : un document de contrôle qualité est créé avec rattachement de photos et tracking lot et série.

**Réception**

* Quantité : la quantité reçue est enregistrée dans le journal des achats.
* Rattachement à la commande : la réception est rattachée à la commande.

**Lignes budget**

* Champs pour remonter le coût budgété ou le montant réel : les lignes budget incluent des champs pour remonter le coût budgété ou le montant réel dans la commande.

3.5. Volume des données

Planification du volume des données

Le processus de planification du volume des données est crucial pour garantir que les besoins des projets sont pris en compte et que les achats sont effectués de manière efficace. Selon les notes sources, il existe trois types d'achats : projets, achats génériques société et achats mutualisés multi-projet.

Pour chaque projet, il est nécessaire de créer une fiche article pour enregistrer les besoins spécifiques du projet. La fiche article doit contenir les informations suivantes : quantité, description, fournisseur, etc. Le journal des achats est utilisé pour enregistrer les achats effectués pour chaque projet.

Le workflow validation est utilisé pour valider les achats avant de passer à la commande. Le processus de validation comprend la vérification des informations fournies par le fournisseur, la vérification des quantités et des prix, ainsi que la vérification des conditions de livraison.

Il est également nécessaire de prendre en compte les informations suivantes pour la planification du volume des données :

- Les besoins des projets (anticipés ou constatés) > achat au niveau de chaque projet
- La gestion des certificats par la Qualité Contrôle
- La prise en compte des différents plannings : planning fournisseur, planning transport, fournisseurs organisés par spécialité
- La gestion des Incoterms : utilisation du champ Shipment Method Code

Il est important de noter que les informations suivantes sont [INFORMATION MANQUANTE] :

- Les processus détaillés d'inspection pour les contrôles qualité
- Les champs pour remonter le coût budgété ou le montant réel dans la commande

Il est également nécessaire de prendre en compte les fonctionnalités souhaitées dans le système, telles que le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système, l'intégration des coûts de transport lié à la commande, etc.

3.6. Écarts critiques et interfaces

**Écarts critiques et interfaces**

**Écarts critiques :**

* L'atelier achats n'utilise pas de document d'entrée en stock, ce qui peut entraîner des difficultés pour le chef de projet pour contrôler et réceptionner les livraisons.
* Il n'y a pas de processus formalisé d'approbation pour les commandes, ce qui peut entraîner des erreurs ou des retards.
* Les certificats ne sont pas toujours nécessaires pour toutes les petites commandes, ce qui peut entraîner des problèmes de traçabilité.
* Il n'y a pas de suivi systématique des inspections à la réception, ce qui peut entraîner des problèmes de qualité.

**Interfaces nécessaires :**

* L'atelier achats doit être connecté au système de gestion de projet pour permettre la consommation des pièces sur les projets.
* Le système de gestion de projet doit être connecté au système de gestion des stocks pour permettre la gestion des stocks et la traçabilité des pièces.
* Le système de gestion des achats doit être connecté au système de facturation pour permettre la gestion des factures et la traçabilité des paiements.
* Le système de gestion des achats doit être connecté au système de gestion des fournisseurs pour permettre la gestion des fournisseurs et la traçabilité des commandes.

**Autres écarts :**

* Il n'y a pas de suivi des lead times fournisseurs.
* Il n'y a pas de prise en compte des différents plannings (fournisseur, transport, etc.).
* Il n'y a pas de gestion des Incoterms.
* Il n'y a pas de suivi des dates de planification dans les lignes projet.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

4 Traitement d‘une livraison directe

4.1. Contexte et Hypothèses

Traitement d'une livraison directe

Contexte et hypothèses :

Actuellement, le processus de traitement des livraisons directes est complexe et nécessite plusieurs étapes manuelles. Le chef de projet donne l'instruction de faire un contrôle qualité léger ou approfondi après réception des colis. Les pièces VOL sont livrées avec des certificats et les documents sont scannés avec la pièce pour assurer la traçabilité. Les lieux de stockage sont situés à Payerne.

Les hypothèses retenues pour ce processus sont :

* La nécessité d'une zone tampon entre la réception du colis et le contrôle qualité.
* La nécessité d'avoir une documentation complète pour chaque commande.
* La nécessité d'intégrer les coûts de transport liés à la commande.
* La nécessité de suivre les lead times fournisseurs et les différents plannings (fournisseur, transport, etc.).
* La nécessité de prendre en compte les différents Incoterms et de préciser la ville pour chaque commande.

Les difficultés rencontrées sont :

* La manuelle de contrôle qualité.
* La nécessité de scanner les documents avec la pièce pour assurer la traçabilité.
* La complexité du processus de traitement des livraisons directes.

Les attentes exprimées sont :

* Mettre en place un flux d'approbation formalisé pour les commandes.
* Intégrer les coûts de transport liés à la commande.
* Suivre les lead times fournisseurs et les différents plannings.
* Prendre en compte les différents Incoterms et préciser la ville pour chaque commande.

Les fonctionnalités souhaitées dans le système sont :

* Suivi de la confirmation de commande fournisseur.
* Date de livraison renseignée dans le système.
* Intégration des coûts de transport liés à la commande.
* Pas d'inspection systématique à la réception.
* Chaque colis reçu est pris en photo.
* Lorsqu'un colis arrive, il n'est pas toujours clair à qui il est destiné.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0

4.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "Warehouse receipt" est créé pour suivre les lots de pièces reçues.
- La qualité doit valider le processus de réception en renseignant les informations nécessaires.
- Les certificats sont gérés par la Qualité Contrôle.
- Les photos des colis reçus sont prises pour assurer la traçabilité.
- Le Chef de Projet donne l'instruction de faire un contrôle qualité léger ou approfondi.
- Les non-conformités sont traitées avec le fournisseur et résolues avant la facturation.
- Les acomptes sont pris en compte pour les fournisseurs qui les demandent.
- Les pièces VOL sont livrées avec des certificats.
- Les lieux de stockage sont définis pour chaque type de pièce.
- Les lead times fournisseurs sont suivis pour planifier les commandes.
- Les différents plannings (fournisseur, transport, etc.) sont pris en compte pour planifier les commandes.
- Le numéro de projet est obligatoire sur le devis pour lier la commande au projet.
- La documentation est jointe à la demande de devis.
- Les champs "Due Date" et "Requested Receipt Date" sont utilisés pour planifier les commandes.
- Le "Shipment Method Code" est utilisé pour gérer les Incoterms.
- Le numéro de projet et les tâches projet sont renseignés sur les lignes pour permettre la consommation sur le projet.
- La réception est validée après validation qualité.
- Les lignes budget sont utilisées pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification sont renseignées dans les lignes projet.

4.4. Documents et statistiques

Génération de documents et statistiques pour la livraison directe

Dans le cadre d'une livraison directe, les documents ERP suivants doivent être générés :

- Fiche de réception de stock (Warehouse Receipt) pour suivre les lots et les séries de pièces.
- Document de contrôle qualité pour valider la réception des pièces.
- Photos des colis reçus pour assurer la traçabilité.
- Lignes budget pour remonter le coût budgété ou le montant réel dans la commande.

Les états ou statistiques nécessaires pour suivre le processus sont :

- Suivi des lead times fournisseurs.
- Prise en compte des différents plannings (fournisseur, transport, etc.).
- Gestion des Incoterms pour détailler les informations de livraison.
- Suivi des quantités reçues et des lignes budget pour remonter les coûts.

Il est important de noter que les certificats sont gérés par la Qualité Contrôle et que les documents d'entrée en stock ne sont pas générés actuellement.

Les champs à renseigner pour les commandes et les réceptions sont :

- Due Date
- Requested Receipt Date
- Numéro de projet
- Tâches projet
- Quantité
- Rattachement à la commande
- Tracking lot et série

Il est également important de définir avec le responsable qualité le processus détaillé d'inspection pour les pièces reçues.

4.5. Volume des données

Traitement d'une livraison directe

Le processus de traitement d'une livraison directe implique plusieurs étapes, notamment la réception, le contrôle qualité et la validation de la livraison.

- **Volume des données** :
- Données référentielles : 3 types d'articles (en stock, non inventory, service), 3 types d'achats (projets, achats génériques société, achats mutualisés multi-projet).
- Nombre de documents ou transactions générés par période :
+ Réception de colis : 1 document par série, 1 document par lot, 1 document par commande.
+ Contrôle qualité : 1 document par série, 1 document par lot, 1 document par commande.
+ Validation de la livraison : 1 document par commande.
- Le processus de traitement d'une livraison directe génère environ 3 à 5 documents par commande, en fonction du type d'article et du niveau de contrôle qualité appliqué.

Il est important de noter que ces volumes de données peuvent varier en fonction des spécificités de chaque projet et de la complexité des commandes.

4.6. Écarts critiques et interfaces

Traitement d'une livraison directe

Écart critique : manque de contrôle qualité systématique à la réception.

Interface nécessaire : intégration des coûts de transport lié à la commande.

Écart critique : pas de document d'entrée en stock, difficulté pour le chef de projet pour contrôler et valider les quantités reçues.

Interface nécessaire : création d'un document d'entrée en stock pour permettre un suivi par lot.

Écart critique : pas de suivi de la confirmation de commande fournisseur.

Interface nécessaire : intégration du suivi de la confirmation de commande fournisseur.

Écart critique : date de livraison non renseignée dans le système.

Interface nécessaire : intégration de la date de livraison dans le système.

Écart critique : pas d'inspection systématique à la réception.

Interface nécessaire : mise en place d'un processus d'inspection détaillé.

Écart critique : chaque colis reçu n'est pas pris en photo.

Interface nécessaire : prise en photo de chaque colis reçu.

Écart critique : le Chef de Projet donne l'instruction de faire un contrôle qualité léger ou approfondi.

Interface nécessaire : mise en place d'un processus de contrôle qualité formalisé.

Écart critique : facture non payée tant que la non-conformité n'est pas résolue.

Interface nécessaire : intégration du suivi des non-conformités et de la résolution des problèmes.

Écart critique : certains fournisseurs demandent des acomptes.

Interface nécessaire : intégration du suivi des acomptes et des paiements.

Écart critique : à la réception, l'atelier scanne les documents avec la pièce pour assurer la traçabilité.

Interface nécessaire : mise en place d'un processus de traçabilité des documents et des pièces.

Écart critique : toutes les pièces VOL sont livrées avec des certificats.

Interface nécessaire : intégration du suivi des certificats et des pièces VOL.

Écart critique : lieu de stockage non précisé.

Interface nécessaire : intégration du lieu de stockage.

Écart critique : suivi des lead times fournisseurs non précisé.

Interface nécessaire : intégration du suivi des lead times fournisseurs.

Écart critique : prise en compte des différents plannings non précisée.

Interface nécessaire : intégration des différents plannings.

Écart critique : numéro de projet obligatoire sur le devis non précisé.

Interface nécessaire : intégration du numéro de projet sur le devis.

Écart critique : documentation à joindre à la demande de devis non précisée.

Interface nécessaire : intégration de la documentation à joindre à la demande de devis.

Écart critique : utilisation des champs Due Date et Requested Receipt Date non précisée.

Interface nécessaire : intégration de l'utilisation des champs Due Date et Requested Receipt Date.

Écart critique : gestion des Incoterms non précisée.

Interface nécessaire : intégration de la gestion des Incoterms.

Écart critique : partie shipping à détailler ultérieurement.

Interface nécessaire : intégration de la partie shipping.

Écart critique : numéro de projet et tâches projet à renseigner sur les lignes non précisés.

Interface nécessaire : intégration du numéro de projet et des tâches projet sur les lignes.

Écart critique : quantité et rattachement à la commande non précisés.

Interface nécessaire : intégration de la quantité et du rattachement à la commande.

Écart critique : création d'un document de contrôle qualité non précisée.

Interface nécessaire : intégration de la création d'un document de contrôle qualité.

Écart critique : tracking lot et série non précisé.

Interface nécessaire : intégration du tracking lot et série.

Écart critique : processus détaillé d'inspection non précisé.

Interface nécessaire : intégration du processus détaillé d'inspection.

Écart critique : lignes budget non précisées.

Interface nécessaire : intégration des lignes budget.

Écart critique : dates de planification dans les lignes projet non précisées.

Interface nécessaire : intégration des dates de planification dans les lignes projet.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

1. Saisie d’une demande de prix

5.1. Contexte et Hypothèses

Saisie d'une demande de prix

Le processus de saisie d'une demande de prix est décrit comme suit :

Lorsque le chef de projet identifie un besoin de projet, il saisit une demande de prix dans le système de gestion de projet. Cette demande de prix est ensuite envoyée aux fournisseurs sélectionnés pour obtenir des offres. Les offres reçues sont rentrées dans le système et associées à la demande de prix.

La demande de prix est ensuite validée par le responsable des achats et logistique, qui vérifie que les offres reçues correspondent aux besoins du projet. Si les offres sont validées, la commande est passée au fournisseur sélectionné.

Le processus de saisie d'une demande de prix est actuellement réalisé de manière manuelle, avec des difficultés pour le chef de projet pour suivre les demandes de prix et les offres reçues. Les attentes exprimées sont d'avoir un flux d'approbation formalisé et de pouvoir suivre les demandes de prix et les offres reçues de manière automatisée.

Les hypothèses identifiées sont :

* La nécessité de mettre en place un flux d'approbation formalisé pour les demandes de prix.
* La nécessité de pouvoir suivre les demandes de prix et les offres reçues de manière automatisée.
* La nécessité de pouvoir lier la commande au projet.

Les fonctionnalités souhaitées dans le système sont :

* Suivi de la confirmation de commande fournisseur.
* Date de livraison renseignée dans le système.
* Intégration des coûts de transport lié à la commande.
* Possibilité de prendre en photo les colis reçus.
* Possibilité de scanner les documents avec la pièce pour assurer la traçabilité.
* Possibilité de suivre les lead times fournisseurs.
* Possibilité de prendre en compte les différents plannings (fournisseur, transport, etc.).

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

• 1. Schéma des processus ERP : Demande de prix 3.0

5.3. Principales règles de gestion

- La demande de prix doit être renseignée avec le numéro de projet obligatoire pour lier la commande au projet.
- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le devis est lié à la commande et doit être renseigné avec les informations pertinentes (due date, requested receipt date, etc.).
- La gestion des Incoterms est nécessaire pour avoir un suivi des dates d'expédition.
- Le processus de réception doit être détaillé avec les quantités, le rattachement à la commande et le contrôle qualité.
- La validation qualité est nécessaire pour valider la réception et générer un document de contrôle qualité avec rattachement de photos et tracking lot et série.
- Les lignes budget doivent être renseignées pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification dans les lignes projet doivent être renseignées pour permettre la consommation sur le projet.

5.4. Documents et statistiques

Saisie d'une demande de prix

La saisie d'une demande de prix est un processus clé dans l'atelier achats. Elle consiste à rentrer les informations nécessaires pour obtenir une offre de prix d'un fournisseur.

**Documents générés**

* Demande de prix fournisseur (Purchase quote)
* Offre fournisseur (Vendor quote)
* Commande (Make Order)

**Rapports et vues métiers**

* Liste de suivi des demandes de prix en cours
* Indicateur de suivi des délais de réponse des fournisseurs
* Export des informations de commande vers Excel

**Nécessités d'impression, de visualisation ou d'export**

* Imprimer la demande de prix fournisseur pour envoyer à l'entreprise
* Visualiser les offres fournisseurs pour comparer les prix et les conditions
* Exporter les informations de commande vers Excel pour la gestion des coûts et des stocks

**Besoins en termes de pilotage et de contrôle**

* Suivre les demandes de prix en cours pour garantir que les délais de réponse sont respectés
* Contrôler les offres fournisseurs pour s'assurer que les prix et les conditions sont raisonnables
* Gérer les commandes pour garantir que les produits sont livrés à temps et dans les bonnes conditions.

5.5. Volume des données

**Saisie d'une demande de prix**

La saisie d'une demande de prix est un processus clé dans l'atelier achats d'Almatech. Cette étape consiste à rentrer les informations nécessaires pour obtenir une offre de prix d'un fournisseur.

**Volume des données référentielles**

* **Fiches articles** : 3 types d'articles (en stock, non-inventoriel, service) sont gérés dans le système.
* **Journal des achats** : pas d'information disponible.
* **Workflow validation** : pas d'information disponible.
* **Demandes de prix** : pas d'information disponible sur le nombre de demandes de prix générées.

**Nombre de documents générés**

* **Demandes de devis** : pas d'information disponible sur le nombre de demandes de devis générées.
* **Offres fournisseurs** : pas d'information disponible sur le nombre d'offres fournisseurs générées.
* **Commandes** : pas d'information disponible sur le nombre de commandes générées.

**Périodes**

* **Jour** : pas d'information disponible.
* **Semaine** : pas d'information disponible.
* **Mois** : pas d'information disponible.
* **Année** : pas d'information disponible.

**[INFORMATION MANQUANTE]**

5.6. Écarts critiques et interfaces

Saisie d'une demande de prix

Lors de la saisie d'une demande de prix, le processus actuel consiste à rentrer les informations nécessaires dans le système, notamment le numéro de projet, les quantités et les informations de planning. La demande de prix est ensuite envoyée au fournisseur pour obtenir une offre.

Cependant, il est prévu de mettre en place un flux d'approbation formalisé pour les commandes, ce qui nécessitera des modifications dans le système pour prendre en compte les approbations nécessaires.

Les interfaces nécessaires avec d'autres systèmes ou services pour la saisie d'une demande de prix incluent :

* L'intégration des coûts de transport liés à la commande
* La prise en compte des différents plannings (planning fournisseur, planning transport, etc.)
* La gestion des Incoterms et la précision de la ville lorsqu'un Incoterm est renseigné

Il est également prévu de scanner les documents avec la pièce à la réception pour assurer la traçabilité, ce qui nécessitera des modifications dans le système pour prendre en compte cette fonctionnalité.

Les objets BC impliqués dans ce processus sont :

* La fiche article pour rentrer les informations nécessaires
* Le journal des achats pour suivre les commandes et les demandes de prix
* Le workflow validation pour prendre en compte les approbations nécessaires
* La gestion des projets et des Work-Packages pour lier la commande au projet
* La gestion des certificats pour prendre en compte les certificats nécessaires pour les pièces VOL.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

6 Saisie d’une commande cadre

6.1. Contexte et Hypothèses

Saisie d'une commande cadre

Le processus de commande cadre est initié par la création d'une demande d'achat dans le système Microsoft Dynamics 365 Business Central. Le responsable achats crée une fiche article pour le projet, qui contient les informations relatives au besoin, tels que la quantité, la date de livraison et le budget.

La demande d'achat est ensuite envoyée aux fournisseurs sélectionnés, qui répondent avec un devis. Le responsable achats renseigne les informations de planning, telles que le lead-time et le stock de sécurité, dans la fiche article.

Une fois le devis accepté, la commande est créée dans le système BC, avec les informations relatives à la livraison, telles que la date de livraison et le mode de transport. Le responsable achats crée également un document de contrôle qualité pour valider la réception des marchandises.

Le processus de commande cadre est suivi par un workflow de validation, qui implique plusieurs étapes, telles que la validation de la commande par le responsable achats, la validation de la réception par le responsable qualité et la validation de la facturation par le responsable financier.

Les difficultés ou points critiques identifiés dans le processus de commande cadre sont :

* La nécessité d'avoir des certificats pour toutes les commandes, ce qui n'est pas toujours nécessaire.
* La difficulté pour le chef de projet de contrôler la réception des marchandises.
* La nécessité d'avoir un flux d'approbation formalisé pour les commandes.

Les attentes exprimées par le client sont :

* Un suivi de la confirmation de commande fournisseur.
* Une date de livraison renseignée dans le système.
* Une intégration des coûts de transport lié à la commande.
* Un processus de contrôle qualité détaillé.

Les hypothèses susceptibles d'influencer le périmètre ou la compréhension du processus sont :

* La disponibilité des données relatives aux fournisseurs et aux marchandises.
* La capacité du système BC à gérer les commandes et les réceptions.
* La disponibilité des ressources humaines pour valider les commandes et les réceptions.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0

6.3. Schéma des processus ERP : Saisie d’une commande d’achat

6.4. Principales règles de gestion

- La commande cadre ne peut être validée que si le devis a été approuvé par le responsable de projet.
- Toute commande cadre doit être rattachée à un projet spécifique.
- Les quantités commandées doivent être cohérentes avec les besoins du projet.
- La date de livraison doit être renseignée dans le système et doit correspondre à la date de livraison prévue par le fournisseur.
- Les coûts de transport liés à la commande doivent être intégrés dans le système.
- Les certificats doivent être joints à la commande pour les pièces VOL.
- Les pièces reçues doivent être scannées avec la pièce pour assurer la traçabilité.
- Les lieux de stockage doivent être précisés pour chaque commande.
- Le numéro de projet doit être obligatoirement renseigné sur le devis pour lier la commande au projet.
- La documentation doit être jointe à la demande de devis.
- Les champs "Due Date" et "Requested Receipt Date" doivent être renseignés pour chaque ligne de commande.
- La gestion des Incoterms doit être prise en compte pour chaque commande.
- Le responsable qualité doit valider la réception avant que la commande ne soit considérée comme validée.
- Les lignes budget doivent être remplies pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification doivent être renseignées dans les lignes projet.
- Le système doit supporter la création d'un document de contrôle qualité avec rattachement de photos et tracking lot et série.
- Le système doit permettre la consommation des pièces sur le projet en fonction du numéro de projet et des tâches projet renseignés sur les lignes.

6.5. Documents et statistiques

Saisie d'une commande cadre

**Documents générés :**

- Commande cadre fournisseur
- État de suivi
- Document de contrôle qualité (avec photos et tracking lot et série)
- Fiche article (pour les articles en stock, non inventory et service)
- Journal des achats (pour le suivi des achats et des commandes)
- Workflow validation (pour la validation des commandes et des documents)

**Statistiques et indicateurs :**

- Suivi des lead times fournisseurs
- Prise en compte des différents plannings (fournisseur, transport, etc.)
- Gestion des incoterms (utilisation du champ Shipment Method Code)
- Numéro de projet obligatoire sur le devis pour lier la commande au projet
- Documentation à joindre à la demande de devis
- Utilisation des champs (Due Date, Requested Receipt Date, etc.)

**Processus :**

1. Saisie d'une commande cadre dans le système
2. Génération d'une commande fournisseur
3. Envoi de la commande au fournisseur
4. Réception des articles et contrôle qualité
5. Validation de la réception et de la commande
6. Mise à jour du journal des achats et de la fiche article
7. Suivi des commandes et des documents à travers le workflow validation

6.6. Volume des données

Saisie d'une commande cadre

La saisie d'une commande cadre est un processus qui consiste à créer une commande pour un projet spécifique. Le processus commence par la création d'un devis, qui est ensuite transformé en commande en 1 clic. Le devis est lié à la commande et le numéro de projet est obligatoire pour lier la commande au projet.

Données référentielles utilisées :

- Fiche article : les articles sont créés dans la fiche article et sont associés à un type d'article (en stock, non inventory, service).
- Journal des achats : les achats sont enregistrés dans le journal des achats et sont associés à un projet spécifique.

Nombre estimé de commandes cadres créées par période :

- Jour : [INFORMATION MANQUANTE]
- Semaine : [INFORMATION MANQUANTE]
- Mois : [INFORMATION MANQUANTE]
- Année : [INFORMATION MANQUANTE]

Le processus de saisie d'une commande cadre est suivi par un workflow de validation qui assure la conformité des données entrées. Le workflow de validation est configuré pour vérifier les champs obligatoires et les plages de valeurs autorisées.

Il est important de noter que le processus de saisie d'une commande cadre est encore en cours de développement et des fonctionnalités supplémentaires sont prévues pour améliorer la gestion des commandes et des projets.

6.7. Écarts critiques et interfaces

**Saisie d'une commande cadre**

Lors de la saisie d'une commande cadre, les écarts critiques entre les pratiques actuelles et la cible attendue dans l'ERP sont les suivants :

* **Absence de document d'entrée en stock** : Actuellement, pas de document d'entrée en stock, ce qui peut entraîner des difficultés pour le chef de projet pour contrôler et valider les réceptions.
* **Gestion des certificats** : Les certificats ne sont pas toujours nécessaires pour toutes les petites commandes, ce qui peut entraîner des difficultés pour la gestion des certificats.
* **Contrôle qualité** : Pas d'inspection systématique à la réception, ce qui peut entraîner des problèmes de qualité.
* **Suivi des lead times fournisseurs** : Pas de suivi des lead times fournisseurs, ce qui peut entraîner des problèmes de livraison.
* **Prise en compte des différents plannings** : Pas de prise en compte des différents plannings (fournisseur, transport, etc.), ce qui peut entraîner des problèmes de livraison.
* **Gestion des Incoterms** : Pas de gestion des Incoterms, ce qui peut entraîner des problèmes de livraison.
* **Numéro de projet obligatoire sur le devis** : Le numéro de projet n'est pas obligatoire sur le devis, ce qui peut entraîner des problèmes de liaison entre la commande et le projet.
* **Documentation à joindre à la demande de devis** : Pas de documentation à joindre à la demande de devis, ce qui peut entraîner des problèmes de traçabilité.

Les interfaces nécessaires pour résoudre ces écarts critiques sont les suivantes :

* **Interface avec le fournisseur** : Pour obtenir les certificats et les informations de livraison.
* **Interface avec le responsable qualité** : Pour obtenir les informations de contrôle qualité.
* **Interface avec le chef de projet** : Pour obtenir les informations de réception et de validation.
* **Interface avec le système de gestion de projet** : Pour obtenir les informations de projet et de tâches.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

7 Saisie d’une commande d‘achat

7.1. Contexte et Hypothèses

Saisie d'une commande d'achat

Contexte et hypothèses

Le processus de saisie des commandes d'achat est complexe et implique plusieurs étapes, notamment la gestion des besoins projet, la création de devis, l'approbation des commandes, la réception des marchandises, le contrôle qualité et la facturation. Actuellement, les commandes sont passées de manière verbale et au feeling, ce qui entraîne des difficultés pour le chef de projet et le responsable achats.

Les hypothèses clés qui influencent le périmètre du processus sont :

* La nécessité de mettre en place un flux d'approbation formalisé pour les commandes.
* La nécessité de suivre la confirmation de commande fournisseur et la date de livraison.
* La nécessité d'intégrer les coûts de transport liés à la commande.
* La nécessité de scanner les documents avec les pièces pour assurer la traçabilité.
* La nécessité de prendre en compte les différents plannings, notamment le planning fournisseur, le planning transport et les fournisseurs organisés par spécialité.

Les besoins exprimés par le client sont :

* La création d'un tableau de bord adapté au profil de l'utilisateur avec les informations pertinentes.
* L'export facile dans Excel.
* La gestion du multi-sourcing, y compris la référence fournisseur.
* La gestion des certificats par la Qualité Contrôle.
* La possibilité de scanner les documents avec les pièces pour assurer la traçabilité.

Les objectifs du client sont :

* Mettre en place un flux d'approbation formalisé pour les commandes.
* Améliorer la traçabilité des commandes et des marchandises.
* Réduire les difficultés pour le chef de projet et le responsable achats.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

7.2 Schéma des processus ERP : Saisie d’une commande d’achat

7.3. Principales règles de gestion

- La commande d'achat ne peut être validée que si le devis est lié à la commande et que le numéro de projet est obligatoirement renseigné.
- Toute pièce reçue doit être scannée avec la pièce pour assurer la traçabilité.
- Les certificats sont obligatoirement joints à la demande de devis pour les pièces VOL.
- La réception est validée par le responsable qualité après création d'un document de contrôle qualité avec rattachement de photos et tracking lot et série.
- Les lignes budget doivent être renseignées pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification doivent être renseignées dans les lignes projet.
- La commande d'achat ne peut être traitée que si le processus d'approbation est formalisé.
- Le suivi de la confirmation de commande fournisseur, la date de livraison et les coûts de transport liés à la commande doivent être intégrés dans le système.
- Les colis reçus doivent être pris en photo et les documents scannés avec la pièce pour assurer la traçabilité.
- Les fournisseurs doivent être organisés par spécialité et les lead times fournisseurs doivent être suivis.
- Les Incoterms doivent être utilisés pour détailler la partie shipping.
- Les tâches projet doivent être renseignées sur les lignes pour permettre la consommation sur le projet.

7.4. Documents et statistiques

Saisie d'une commande d'achat

La commande d'achat est générée à partir d'une demande d'offre (Purchase quote) qui est envoyée au fournisseur. L'utilisateur renseigne les informations suivantes :

* Le numéro de projet (pour lier la commande au projet)
* Les informations de planning (lead-time, stock de sécurité, Minimum Order Quantity, etc.)
* Les informations de paiement (acomptes, etc.)

La commande d'achat est ensuite validée par le workflow de validation (workflow validation) et est envoyée au fournisseur.

Documents générés :

* Demande d'offre (Purchase quote)
* Commande d'achat (Make Order)
* Document de contrôle qualité (avec rattachement de photos)

Informations clés attendues :

* Numéro de projet
* Informations de planning
* Informations de paiement
* Date de livraison
* Quantité
* Rattachement à la commande

États, statistiques ou indicateurs nécessaires pour suivre ou analyser le processus :

* Suivi de la confirmation de commande fournisseur
* Date de livraison renseignée dans le système
* Intégration des coûts de transport lié à la commande
* Suivi des lead times fournisseurs
* Prise en compte des différents plannings (fournisseur, transport, etc.)

Note : Il est important de noter que certains documents tels que le document d'entrée en stock ne sont pas encore générés dans le système.

7.5. Volume des données

Saisie d'une commande d'achat

La saisie d'une commande d'achat dans Microsoft Dynamics 365 Business Central implique plusieurs étapes.

Données référentielles utilisées :

- Fiche article : les informations de base sur les articles, tels que le nom, le code, la description, les dimensions, le poids, etc.
- Fournisseur : les informations sur les fournisseurs, tels que le nom, l'adresse, le numéro de téléphone, etc.
- Projet : les informations sur les projets, tels que le nom, le budget, les dates de début et de fin, etc.

Nombre moyen de commandes d'achat créées sur une période :

- Selon les informations disponibles, il n'y a pas de données précises sur le nombre moyen de commandes d'achat créées sur une période. [INFORMATION MANQUANTE]

Processus de saisie d'une commande d'achat :

1. Création d'une demande d'achat : le responsable achats crée une demande d'achat pour un projet spécifique, en sélectionnant les articles nécessaires et les quantités requises.
2. Demande d'offre : la demande d'achat est envoyée aux fournisseurs sélectionnés, qui répondent avec un devis.
3. Analyse des offres : le responsable achats analyse les offres reçues et sélectionne la meilleure offre.
4. Création d'une commande : la commande est créée en fonction de l'offre sélectionnée, en incluant les informations de base sur les articles, les quantités, les prix, etc.
5. Approbation de la commande : la commande est soumise à l'approbation de la hiérarchie, en fonction du seuil défini.
6. Réception des articles : les articles sont reçus et vérifiés par le responsable qualité.
7. Validation de la réception : la réception est validée par le responsable qualité, en fonction du processus d'inspection défini.

Les données référentielles utilisées sont stockées dans les tables suivantes :

- Table "Article" pour les informations de base sur les articles.
- Table "Fournisseur" pour les informations sur les fournisseurs.
- Table "Projet" pour les informations sur les projets.
- Table "Commande" pour les informations sur les commandes.
- Table "Réception" pour les informations sur les réceptions.

Les objets BC utilisés sont :

- Fiche article
- Journal des achats
- Workflow validation
- Table "Article"
- Table "Fournisseur"
- Table "Projet"
- Table "Commande"
- Table "Réception"

7.6. Écarts critiques et interfaces

Saisie d'une commande d'achat

Lors de la saisie d'une commande d'achat, le processus actuel consiste à passer par une chaîne d'approbation basée sur un seuil dépendant de la personne qui passe la commande ou du risque sur la commande. Le critère d'approbation est l'achat dans le budget ou pas.

L'interface utilisateur est adaptée au profil de l'utilisateur avec les informations pertinentes. Les données sont exportables facilement dans Excel.

Lors de la saisie d'une commande d'achat, il est possible de choisir entre trois types d'articles : en stock, non inventory (sans gestion de stock) et service.

La gestion du multi-sourcing est possible, y compris la référence fournisseur. Les informations de planning, telles que le lead-time, le stock de sécurité et le Minimum Order Quantity, sont également prises en compte.

La saisie d'une commande d'achat implique également la création d'un "Purchase quote" (demande d'offre à adresser au fournisseur) et la rentrée des offres fournisseurs. Les offres peuvent ensuite être transformées en commandes en 1 clic.

Il n'y a pas de document d'entrée en stock, ce qui peut poser des difficultés pour le chef de projet. Il est possible de créer un Warehouse receipt afin de suivre les lots.

Les commandes sont liées aux projets et les quantités sont rattachées à la commande. Le contrôle qualité est effectué en créant un document de contrôle qualité avec rattachement de photos.

Il est possible de suivre les lead times fournisseurs et de prendre en compte les différents plannings, tels que le planning fournisseur, le planning transport et les fournisseurs organisés par spécialité.

Les champs "Due Date" et "Requested Receipt Date" sont utilisés pour la saisie d'une commande d'achat.

Il est également possible de gérer les Incoterms et les champs "Shipment Method Code" et "City" sont utilisés pour cela.

Enfin, la saisie d'une commande d'achat implique également la gestion des lignes budget et des dates de planification dans les lignes projet.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

8 Saisie d’un retour d’une commande achat

8.1. Contexte et Hypothèses

Saisie d'un retour d'une commande achat

Le processus de gestion des retours fournisseurs est actuellement basé sur un contrôle qualité léger ou approfondi effectué par l'ingénieur ou le Chef de Projet (CP) à la réception des colis. Le CP donne l'instruction de faire un contrôle qualité en fonction de la nature du colis. En cas de non-conformité, l'ingénieur ou le CP discute directement avec le fournisseur pour résoudre le problème. La facture n'est payée que lorsque la non-conformité est résolue.

Actuellement, il n'y a pas de document d'entrée en stock, ce qui peut poser des difficultés pour le chef de projet. Le processus de réception est détaillé dans les notes sources, mais il n'y a pas de processus formalisé pour les retours.

Les hypothèses susceptibles d'avoir un impact sur la définition ou la mise en œuvre du processus sont les suivantes :

- La qualité des données : les informations renseignées dans le système doivent être précises pour permettre une gestion efficace des retours.
- L'outillage existant : le système doit être capable de gérer les retours de manière efficace et automatisée.
- Les dépendances organisationnelles : le processus de gestion des retours doit être aligné avec les processus existants de la société.

Il est nécessaire de mettre en place un processus formalisé pour les retours, qui doit prendre en compte les spécificités de chaque projet et fournisseur. Le système doit être capable de gérer les retours de manière efficace et automatisée, en prenant en compte les hypothèses mentionnées ci-dessus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0

8.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "journal des achats" doit être utilisé pour enregistrer les mouvements de stock liés aux retours de commande.
- Le "workflow validation" doit être configuré pour valider les retours de commande avant de les marquer comme "réceptionnés".
- Le "fiche article" doit être mis à jour pour refléter les modifications apportées aux pièces retournées.
- Les "photos des colis" doivent être prises et associées à chaque retour de commande pour assurer la traçabilité.
- Le "contrôle qualité" doit être effectué avant de marquer les pièces comme "réceptionnées".
- Les "certificats" doivent être vérifiés et enregistrés dans le système pour chaque retour de commande.
- Le "suivi des lead times fournisseurs" doit être pris en compte pour planifier les retours de commande.
- Les "plannings" (fournisseur, transport, etc.) doivent être pris en compte pour planifier les retours de commande.
- Le "numéro de projet" doit être obligatoirement renseigné pour chaque retour de commande pour lier la commande au projet.

8.4. Documents et statistiques

Saisie d'un retour d'une commande achat

Lorsqu'un retour d'une commande achat est nécessaire, le processus suivant est mis en œuvre :

1. Le chef de projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi.
2. Le responsable qualité crée un document de contrôle qualité avec rattachement de photos.
3. Le tracking lot et série est effectué.
4. Lorsque le responsable qualité valide, la réception est validée.

Documents à générer :

* Document de contrôle qualité
* Photos de la réception
* Tracking lot et série

États, rapports ou statistiques attendus :

* État de la réception avec validation qualité
* Statistiques de retour de commande achat
* Rapport de contrôle qualité

Il est important de noter que la saisie d'un retour d'une commande achat nécessite une validation qualité avant de poursuivre le processus.

8.5. Volume des données

Saisie d'un retour d'une commande achat

Le processus de saisie d'un retour d'une commande achat est décrit dans les notes sources. Selon ces informations, un retour d'une commande achat est traité comme suit :

- Lorsque le produit livré ne correspond pas à la commande, le chef de projet donne l'instruction de faire un contrôle qualité léger ou approfondi.
- L'ingénieur ou le chef de projet discute directement avec le fournisseur en cas de non-conformité.
- La facture n'est pas payée tant que la non-conformité n'est pas résolue.

Volume des données

- Le nombre de retours par période n'est pas spécifié dans les notes sources.
- Les types d'articles concernés sont les composants ou les licences.
- Le volume documentaire lié à ce processus est important, car il implique la saisie de documents tels que les photos des colis, les certificats, les documents de contrôle qualité, etc.
- Les données référentielles utiles liées à ce processus incluent les informations sur les fournisseurs, les projets, les commandes, les livraisons, les pièces, les certificats, etc.

Il est important de noter que certaines informations sont manquantes dans les notes sources, telles que le nombre de retours par période et le volume documentaire précis.

8.6. Écarts critiques et interfaces

Saisie d'un retour d'une commande achat

Lorsqu'un retour d'une commande achat est effectué, il est nécessaire de suivre un processus spécifique pour garantir que les écarts critiques sont identifiés et suivis. Actuellement, le processus de retour d'une commande achat n'est pas formalisé et dépend de la personne qui passe la commande ou du risque sur la commande.

Dans le système BC, il est possible de suivre les commandes achat à travers la table "Journal des achats". Cependant, il n'y a pas de fonctionnalité pour suivre les retours de commande achat.

Pour améliorer ce processus, il est nécessaire de mettre en place un flux d'approbation formalisé pour les retours de commande achat. Cela implique de créer un workflow validation pour les retours de commande achat, qui sera suivi par le responsable qualité et le chef de projet.

Il est également nécessaire de suivre les écarts critiques entre les pratiques actuelles et les pratiques cibles, notamment en ce qui concerne la gestion des retours de commande achat. Cela implique de suivre les interfaces nécessaires avec d'autres applications ou départements, tels que la gestion des stocks et la facturation.

Enfin, il est nécessaire de documenter les étapes du processus de retour d'une commande achat pour garantir que les informations sont claires et accessibles pour tous les acteurs concernés.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

9 Rapports achat

9.1. Contexte et Hypothèses

**Processus : Rapports achat**

**9.1. Contexte et Hypothèses**

Le processus de rapports achat vise à fournir des informations précises et à jour sur les achats de l'entreprise. Les besoins en analyses sont les suivants :

* Suivi des commandes en cours et des livraisons attendues
* Contrôle des coûts et des délais de livraison
* Gestion des fournisseurs et des incoterms
* Suivi des pièces et des certificats

Les points critiques identifiés sont :

* La disponibilité et la qualité des données
* La granularité des rapports
* La capacité d'export des données

Les attentes pour la mise à disposition de rapports ou tableaux de bord sont :

* Un tableau de bord adapté au profil de l'utilisateur avec les informations pertinentes
* Un export facile dans Excel
* Un suivi en temps réel des commandes et des livraisons

Les hypothèses susceptibles d'influencer la conception du reporting sont :

* La disponibilité des données dans le système
* La qualité des données saisies
* La capacité du système à gérer les grandes quantités de données

Les fonctionnalités souhaitées dans le système sont :

* Suivi de la confirmation de commande fournisseur
* Date de livraison renseignée dans le système
* Intégration des coûts de transport lié à la commande
* Suivi des lead times fournisseurs
* Prise en compte des différents plannings (fournisseur, transport, etc.)

Il est important de noter que certains fournisseurs demandent des acomptes et que la facture n'est pas payée tant que la non-conformité n'est pas résolue.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

9.2 Schéma des processus ERP : Rapport achat 8.0

9.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Les commandes doivent être liées à un projet pour permettre la consommation sur le projet.
- Le numéro de projet est obligatoire sur le devis pour lier la commande au projet.
- Les certificats sont nécessaires pour les pièces VOL.
- Les lieux de stockage sont : Payerne.
- Le suivi des lead times fournisseurs est nécessaire.
- Les différents plannings (fournisseur, transport, spécialité) doivent être pris en compte.
- La documentation doit être jointe à la demande de devis.
- Les champs "Due Date" et "Requested Receipt Date" doivent être utilisés.
- La gestion des Incoterms est nécessaire, notamment l'utilisation du champ "Shipment Method Code".
- La partie shipping doit être détaillée ultérieurement.
- Les lignes de commande doivent être rattachées à la commande.
- Le contrôle qualité doit être effectué avant la validation de la réception.
- Un document de contrôle qualité doit être créé avec rattachement de photos, tracking lot et série.
- Les dates de planification doivent être remontées dans les lignes projet.
- Les lignes budget doivent comporter des champs pour remonter le coût budgété ou le montant réel dans la commande.

9.4. Documents et statistiques

**Processus : Rapports achat**

**Section : 9.4. Documents et statistiques**

Les documents et états suivants sont attendus pour assurer un suivi fiable de l'activité achat :

- **Fiche article** : les trois types d'articles (en stock, non inventory et service) doivent être clairement identifiés.
- **Journal des achats** : il doit contenir les informations suivantes :
+ Les besoins projets (anticipés ou constatés) avec les quantités et les dates.
+ Les achats génériques société (licences, ordinateurs...).
+ Les achats mutualisés multi-projet.
- **Workflow validation** : il doit être mis en place un flux d'approbation formalisé pour les commandes.
- **Tableau de bord** : un tableau de bord adapté au profil de l'utilisateur doit être disponible pour afficher les informations pertinentes.
- **Export en Excel** : les données doivent être exportables facilement en Excel.
- **Statistiques** : les statistiques suivantes doivent être disponibles :
+ Le suivi des lead times fournisseurs.
+ La prise en compte des différents plannings (fournisseur, transport, spécialité).
+ Le suivi des certificats.

Les indicateurs suivants doivent être disponibles :

- **Taux de conformité** : le taux de conformité des produits reçus.
- **Temps de réception** : le temps de réception des produits.
- **Coûts de transport** : les coûts de transport liés aux commandes.
- **Nombre de non-conformités** : le nombre de non-conformités détectées.

9.5. Volume des données

Rapports achat : Volume des données

Le processus d'achat utilise les fiches articles pour gérer les besoins des projets et des commandes génériques. Les données historiques utilisées incluent les lignes de factures et de commandes, ainsi que les informations de planning telles que les lead times et les stocks de sécurité.

Le nombre de lignes de factures est de [INFORMATION MANQUANTE], tandis que le nombre de lignes de commandes est de [INFORMATION MANQUANTE]. Les données de planning sont également importantes, notamment les lead times fournisseurs, les plannings transport et les fournisseurs organisés par spécialité.

Le journal des achats est utilisé pour suivre les commandes et les factures, tandis que le workflow validation est utilisé pour formaliser le flux d'approbation. Les données de contrôle qualité sont également importantes, notamment les photos des colis reçus et les documents de contrôle qualité.

Enfin, les données de budget et de coûts sont également importantes, notamment les lignes budget et les champs pour remonter le coût budgété ou le montant réel dans la commande.

9.6. Ecarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

10 Historique achat

10.1. Contexte et Hypothèses

Historique achat

Contexte et hypothèses

Le processus d'achat actuel est basé sur un atelier d'achat où les besoins des projets sont anticipés ou constatés, puis les achats sont passés au niveau de chaque projet. Les achats sont classés en trois types : projets, achats génériques société et achats mutualisés multi-projet. Les achats sont suivis à travers la chaîne d'approbation, qui dépend du seuil défini en fonction de la personne qui passe la commande ou du risque sur la commande.

Les difficultés rencontrées sont la gestion des certificats, la prise en compte des différents plannings, la gestion des coûts et la traçabilité des pièces. Les attentes du client sont la mise en place d'un flux d'approbation formalisé, le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système et l'intégration des coûts de transport lié à la commande.

Les hypothèses susceptibles d'avoir un impact sur la reprise ou l'exploitation de l'historique sont la mise en place d'un système de gestion de l'approbation, la création d'un document d'entrée en stock et la gestion des certificats.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

10.2 Schéma des processus ERP : Historique achat 9.0

10.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "journal des achats" permet de suivre les commandes et les livraisons.
- Le "workflow validation" permet de définir les étapes de validation qualité et de réception.
- Les "fiches article" contiennent les informations sur les pièces, y compris les certificats.
- Le "tableau de bord" adapté au profil de l'utilisateur permet de visualiser les informations pertinentes.
- Les "export" vers Excel permettent de faciliter la gestion des données.
- Les "commandes" sont liées aux "projets" et aux "fournisseurs".
- Les "livraisons" sont suivies dans le "journal des achats".
- Les "pièces" sont étiquetées avec un numéro de série unique généré par le système.
- Les "sur-réceptions" génèrent automatiquement un surplus affecté au stock projet ou général selon la codification.

10.4. Documents et statistiques

**Processus : Historique achat**

**Documents et statistiques**

Pour suivre l'activité d'achat, il est important de consulter les documents suivants :

- **Fiche article** : pour vérifier les informations relatives aux articles commandés, notamment les quantités, les prix et les fournisseurs.
- **Journal des achats** : pour suivre les commandes passées, les livraisons reçues et les paiements effectués.
- **Workflow validation** : pour vérifier les étapes de validation des commandes et des livraisons.
- **Tableau de bord adapté au profil** : pour obtenir des informations pertinentes sur l'activité d'achat, telles que les commandes en cours, les livraisons à venir et les paiements à effectuer.
- **Export dans Excel** : pour analyser les données d'achat de manière détaillée et personnalisée.

Les statistiques utiles pour suivre l'activité d'achat incluent :

- **Nombre de commandes passées** : pour évaluer la fréquence des achats.
- **Montant total des commandes** : pour évaluer le volume d'achat.
- **Temps de livraison** : pour évaluer la rapidité de livraison des fournisseurs.
- **Taux de conformité** : pour évaluer la qualité des produits reçus.
- **Coûts de transport** : pour évaluer les coûts associés à la livraison des produits.

Il est important de noter que ces informations sont disponibles dans le système de gestion de l'entreprise, et peuvent être consultées et analysées en fonction des besoins.

10.5. Volume des données

10.5. Volume des données

Les données historiques à reprendre ou à conserver incluent les fiches articles, les commandes, les factures, les livraisons, les contrôles qualité et les documents de réception. La période de reprise est à définir en fonction des besoins de l'entreprise.

Nombre estimé de documents :

- Fiches articles : [INFORMATION MANQUANTE]
- Commandes : [INFORMATION MANQUANTE]
- Factures : [INFORMATION MANQUANTE]
- Livraisons : [INFORMATION MANQUANTE]
- Contrôles qualité : [INFORMATION MANQUANTE]
- Documents de réception : [INFORMATION MANQUANTE]

Données référentielles associées :

- Fournisseurs : [INFORMATION MANQUANTE]
- Projets : [INFORMATION MANQUANTE]
- Articles : [INFORMATION MANQUANTE]
- Incoterms : [INFORMATION MANQUANTE]
- Lieux de stockage : [INFORMATION MANQUANTE]

Le processus d'achat comprend les étapes suivantes :

- Demande de devis
- Approbation de la commande
- Réception des marchandises
- Contrôle qualité
- Validation de la réception
- Facturation

Les données historiques seront stockées dans les tableaux suivants de Microsoft Dynamics 365 Business Central :

- Tableau "Articles" pour les fiches articles
- Tableau "Commandes" pour les commandes
- Tableau "Factures" pour les factures
- Tableau "Livraisons" pour les livraisons
- Tableau "Contrôles qualité" pour les contrôles qualité
- Tableau "Documents de réception" pour les documents de réception

Il est important de noter que les volumes de données peuvent varier en fonction des besoins spécifiques de l'entreprise. Il est donc recommandé de consulter les notes sources pour obtenir des informations plus précises.

10.6. Écarts critiques et interfaces

Identifier les écarts critiques ou interfaces nécessaires autour de la gestion de l’historique d’achat.

- **Écart critique 1 :** Manque de suivi de la confirmation de commande fournisseur.
- **Écart critique 2 :** Date de livraison non renseignée dans le système.
- **Écart critique 3 :** Intégration des coûts de transport lié à la commande.
- **Écart critique 4 :** Pas d’inspection systématique à la réception.
- **Écart critique 5 :** Chaque colis reçu n’est pas pris en photo.
- **Écart critique 6 :** Lorsqu’un colis arrive, il n’est pas toujours clair à qui il est destiné.
- **Écart critique 7 :** Le Chef de Projet (CP) donne l’instruction de faire un contrôle qualité léger ou approfondi.
- **Écart critique 8 :** L’ingénieur ou le CP discute directement avec le fournisseur en cas de non-conformité.
- **Écart critique 9 :** Facture non payée tant que la non-conformité n’est pas résolue.
- **Écart critique 10 :** Certains fournisseurs demandent des acomptes.
- **Écart critique 11 :** À la réception, l’atelier scanne les documents avec la pièce pour assurer la traçabilité.
- **Écart critique 12 :** Toutes les pièces VOL sont livrées avec des certificats.
- **Écart critique 13 :** Lieux de stockage : Payerne.
- **Écart critique 14 :** Suivi des lead times fournisseurs.
- **Écart critique 15 :** Prise en compte des différents plannings : planning fournisseur, planning transport, fournisseurs organisés par spécialité.
- **Écart critique 16 :** Numéro de projet obligatoire sur le devis pour lier la commande au projet.
- **Écart critique 17 :** Documentation à joindre à la demande de devis.
- **Écart critique 18 :** Utilisation des champs : Due Date, Requested Receipt Date.
- **Écart critique 19 :** Gestion des Incoterms : utilisation du champ Shipment Method Code.
- **Écart critique 20 :** Numéro de projet et tâches projet à renseigner sur les lignes pour permettre la consommation sur le projet.

Ces écarts critiques et interfaces nécessaires autour de la gestion de l’historique d’achat devront être intégrés dans la liste des écarts clôturée en fin de phase d’Analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

11 Annexe 1 : Liste d‘écarts

11.1. Liste d’écarts

11.1. Liste d'écarts

La liste d'écarts doit être initialisée et finalisée à la fin de la phase d'Analyse. Elle sera stockée dans SharePoint.

Pour créer la liste d'écarts, il faut suivre les étapes suivantes :

1. Créer un document de contrôle qualité pour chaque colis reçu.
2. Rattacher des photos au document de contrôle qualité.
3. Rattacher des informations de tracking lot et série.
4. Valider la réception par le responsable qualité.
5. Remonter les coûts budgétés ou les montants réels dans la commande.

La liste d'écarts sera utilisée pour suivre les écarts de qualité et les non-conformités. Elle permettra de prendre des mesures correctives pour améliorer la qualité des produits reçus.

Il est important de noter que la liste d'écarts doit être mise à jour régulièrement pour refléter les dernières informations disponibles.

**Objets BC utilisés** :

- Fiche article
- Journal des achats
- Workflow validation
- Document de contrôle qualité
- Photos
- Tracking lot et série
- Lignes budget
- Dates de planification dans les lignes projet

**Informations manquantes** : [INFORMATION MANQUANTE]

Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).